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DECLARATION OF DR. DAVID R, LEVINE 

I, David R. Levine, declare as follows. 

1 . I hold the following degrees: 

• Ph.D., Computer Science, Stanford University (1 973) 

• M.S., Computer Science, Stanford University (1968) 

• B.A., Physics, Harvard University (1965) 

2. My professional experience includes: 



• 38 years working as a computer scientist in a variety of areas, including operating 
systems, programming language design, compilers and optimization, and 
instruction set architecture design 

• Assistant Professor of Computer Science at Rutgers University 

• Assistant Professor of Computer Science at Boston College 

• Adjunct Lecturer in Computer Science at the University of Massachusetts 

• Co-inventor on U.S. Patent No. 6,332,188 for features in the instruction set 
architecture of Analog Devices' TigerSHARC processor 
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• Member of the ANSI Fortran Language Standards committee (X3J3) 
(representing Hewlett-Packard Company), and also the ANSI Parallel Computing 
Committee (X3H5), both committees relating to parallel execution 

• At Stanford, I was one of four key designer/implementers of a multi-user 
timesharing system. One of my specific responsibilities involved the design, 
implementation and maintenance of intemipt handlers, and their interaction with 
general process scheduling. 

• I am currently working on an operating system project, with responsibilities in the 
area of interrupt and exception handlers. 

3. In preparing this declaration, I have reviewed the following portions of the prosecution 
history for application serial no. 09/672,440: 

• Office Action of 5/17/2006 

• The specification of this application 

• U.S. Pat. No. 5,121,472, Danish, Method for Replacing Keyboard Data Using 
Single Step Process Mode 

• The online version of MPEP §§ 2143.01, describing the legal concept of 
suggestion or motivation to modify or combine references 

4. I also rely on my personal knowledge in the art, and the plain meaning given terms in the art. 



I. Hardware and Software are NOT Equivalent for "Motivation to Modify" Purposes 

5. Paragraph 5 of The Office Action states as follows: 

...Tannenbaum taught hardware and software are logically equivalent and any 
operation performed by software can also be built directly into hardware and any 
instruction executed by hardware can also be simulated in software. The 
decision to put certain functions in hardware and others in software is based on 
such factors as cost, speed, reliability, and frequency of expected changes, 
(e.g., see page 4). Consequently one of ordinary skill implementing he 
operations of the Danish [sic] would have been motivated to implement all or part 
of the Danish system in hardware depending on cost, speed, reliability and 
frequency of expected changes. 

6. The first two sentences quoted above are true, but only in an theoretical, academic, abstract 
sense. As a matter of computational theory, with sufficient resources and freedom from 
practical constraints, anything implemented in one computation technology can theoretically 
be rebuilt in another technology to have "logically" the same behavior. However, in the 
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practical world, where those of ordinary skill in the art practice, the abstract, theoretical 
proposition stated in these two sentences is simply not true - many tasks must be done in 
hardware or must be done in software to be practical. 

7. Danish's technique is one of the latter - any practical implementation of Danish using the 
techniques available in the late 1990's to 2000 would have to be in software. 

8. The Office Action (5 5) correctly notes that "such factors as cost, speed, reliability and 
frequency of expected changes" might enter any choice between hardware and software 
implementation. However, the Office Action is simply silent on identifying any particular 
factor relating to "cost, speed, reliability and frequency of expected changes" that would 
apply to Danish '472 to suggest the desirability of hardware implementation. With no such 
showing, I cannot comment on any view the Examiner might hold, except to note that the 
Examiner's conclusions are entirely unsupported. 

9. My opinion as one of ordinary skill is that any attempt to implement Danish's system in 
hardware using the techniques available in the late 1990's to 2000 would be unreasonable in 
"cost." 

10. My opinion as one of ordinary skill is that Danish's system would not offer any motivation 
for any "speed" benefit available from hardware using the techniques available in the late 
1990's to 2000 - Danish only needs to operate at the speed at which a human can type at a 
keyboard. 

1 1. My opinion as one of ordinary skill is that hardware implementation of Danish's system 
using the techniques available in the late 1990's to 2000 would be sufficiently complex that it 
would not attain "reliability" benefits. 

12. My opinion as one of ordinary skill is that the "frequency of expected changes" for Danish's 
system would be sufficiently high that implementation in hardware using the techniques 
available in the late 1990's to 2000 would be impractical and undesirable. 

13. The Office Action is likewise silent on identifying "desirability" of hardware implementation 
of Danish's invention using the techniques available in the late 1990's to 2000, and therefore 
I cannot comment on any view the Examiner might hold. 

14. There would be other factors that would also weigh against a decision to implement Danish's 
system in hardware, at least using the techniques available in the late 1990*s to 2000. 
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15. 



I understand that MPEP § 2i43.0I(m) bars an examiner from relying on "the mere fact that 
references can be combined or modified" as a basis for asserting obviousness. In my 
opinion, the Office Action engages in exactly the reasoning that is forbidden. 



II. The Office Action Misstates the Content of the Danish Reference 

16. Paragraph 4 of the Office Action reads as follows: 

[the single step handler examines the next instruction in hardware interrupt 
handler to see if it is an instruction to retrieve data from the keyboard... This 
keyboard input instruction provides data to be used by instruction to be 
executed, and provides an interrupt to instruction processing... and therefore 
affects the function of instructions to be performed], and in response, ... taking a 
single step exception after executing the second instruction... 

17. This is not correct. Though the Office Action is ambiguous, it appears that the instruction of 
Danish 9 472 that the Office Action identifies as corresponding tc the "second instruction" of 
the claims of this application is not executed at all , but rather is bypassed. Fig. 2, box 38, 
item 1 . Alternatively, the Office Action may have intended to compare the "keyboard input 
instruction" of Danish '472 to the first "instruction" of the claims, but this analysis would 
also be faulty: in Danish, the single step mode is in effect before execution of the "keyboard 
input instruction," rather than being "set" "in response to" the "recognizing" recited in the 
claims. In either of the possible interpretations of the Office Action text, the two systems are 
clearly different. 

18. Paragraph 7 of the Office Action is wrong. Danish '472, col. 6, line 31 mentions a "stack 
pointer." A "stack pointer" and a "stack segment register" are different things and do not 
perform the same "operation." The Office Action does not explain the pertinence of the 
"stack register" sufficiently for me to diagnose or respond to the error in the Examiner's 
understanding. 

19. Paragraph 8 of the Office Action is wrong. The term "debug touch record" is clear in the 
context of the application's specification, and it does not mean "a record of keyboard 
input. . ." or "a record of . . . which keyboard keys were touched for simulation." 

VI. Conclusion 
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20. 1 express no opinion on any issue not expressly set forth above, and reserve the right to opine 
further if necessary. The opinions I have stated are specific to the particular facts before me 
today. In some cases, I have opined to a general rule that might have exceptions, but no 
exceptions that I know of are relevant to the issues before me today. 

21. 1 declare that all statements made herein of my own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that these 
statements were made with the knowledge that willful false statements and the like so made 
are punishable by fine or imprisonment, or both, under 18 U.S.C. § 1001 and that such 
willful false statements may jeopardize the validity of the application or any patent issuing 
thereon. 



Respectfully submitted, 
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